Code Review

Overview

This PR consolidates 3 separate Windows CI jobs (build-windows → sign-windows → bundle-windows) into a single job by using Tauri v2's signCommand hook for DigiCert SSM signing. It also fixes several configuration issues that were silently breaking bundling.

Verdict: Solid improvement. The architecture change is well-motivated and the approach is correct. A few items worth discussing before merge.

What's Good

• 3 jobs → 1 is a meaningful win. Eliminates artifact upload/download round-trips, removes the fragile Autonomi.exe filename assumption (the binary is actually ant-gui.exe), and cuts billable CI minutes.
• signCommand is the canonical Tauri v2 approach — much cleaner than the manual build → sign → rebundle-with---no-compile pipeline.
• bundle.active: true is a critical fix. Without it, bundling was being silently skipped.
• .msi / .msi.sig is correct for Tauri v2. The old .msi.zip / .msi.zip.sig artifacts are a Tauri v1 pattern.
• Icon paths are valid — all 6 referenced files exist in src-tauri/icons/.
• Job dependency graph is correct: build-windows waits on build-linux-macos (which creates the draft release via tauri-action), ensuring gh release upload has a target.

Issues

1. Dropped signature verification (Medium)

The old workflow had an explicit post-signing check:

# OLD - removed in this PR
$sig = Get-AuthenticodeSignature "artifacts\Autonomi.exe"
if ($sig.Status -ne "Valid") {
    Write-Error "Signature validation failed"
    exit 1
}

The new workflow relies entirely on smctl sign returning a non-zero exit code if signing fails. If smctl ever exits 0 without actually applying a signature (tool misconfiguration, partial failure, wrong keypair alias), nothing catches it.

Recommendation: Add a verification step after the build completes — either a Get-AuthenticodeSignature check on the produced .msi, or at minimum a signtool verify on the binary inside the MSI. This was a good safety net that's worth preserving.

2. sign.cmd quoting: %1 should be "%~1" (Low)

smctl sign --keypair-alias "$env:SM_KEYPAIR_ALIAS" --input %1

If the file path ever contains spaces, %1 will truncate at the first space. The defensive pattern in batch is "%~1" (strips surrounding quotes from the arg, then re-quotes). Not a practical issue in GitHub Actions runners (paths are space-free), but a robustness concern if the build environment ever changes.

3. signCommand and %1 double-substitution clarity (Nit)

The signCommand config is:

npx tauri build --bundles msi,updater --config "{`"bundle`":{`"windows`":{`"signCommand`":`"$signCmd %1`"}}}"

Tauri's bundler replaces %1 in the signCommand string with the file path, then executes the result. Inside sign.cmd, the batch %1 parameter then also receives the file path (as the first argument). Both substitution levels happen to produce the correct result, but it reads as if %1 is doing two things. A brief inline comment explaining the mechanism would help the next person who reads this.

4. endswith(".msi") selector could match unexpected assets (Low)

In update-latest-json:

msi_url=$(gh release view "$tag" --repo "$GITHUB_REPOSITORY" --json assets \
  --jq '.assets[] | select(.name | endswith(".msi")) | .url')

This would match any asset ending in .msi. If a second .msi is ever uploaded to the release, msi_url would contain multiple URLs, breaking the subsequent jq command. A tighter selector (e.g., test("ant-gui.*\.msi$")) would be more resilient.

5. No cleanup of sign.cmd (Nit)

The script is written to the workspace root and never removed. Harmless on ephemeral CI runners, but if this workflow is ever adapted for a self-hosted runner, the script (containing the keypair alias) would persist. A Remove-Item after the build step would be good hygiene.

Summary

Overall: Clean, well-tested improvement. Issue #1 (dropped verification) is the only one I'd want addressed before merge — the rest are hardening suggestions. The consolidation from 3 jobs to 1 using Tauri's native signCommand is the right architectural direction.